Most computer processors have one or more control registers that determine how the computer processor operates. The control register settings may affect things such as instruction fetching, data memory references, and instruction execution behavior. Examples of control register settings include the enabling or disabling of virtual memory translation for instruction fetches, specifying the Little endian or Big Endian nature of data memory references, and the enabling or disabling of processor operating modes such as a supervisor mode for operating systems and a user mode for user programs.
In order for a computer processor to generate predictable results, the processor must respond to changes in control registers in a consistent and well documented manner. Specifically, the effects produced by a control register modification must be observable at a well defined time. In this manner, programmers can rely upon the processor to generate the same results for the same instruction stream.
However, ensuring that the effects of a control register are always observed at a well defined time can be difficult task. Most processors progress through several successive processor generations. Each processor generation will be implemented differently and thus will have a different latency time. Two different methods have been devised to solve this problem: self-serializing processors and defined maximum latency times.
Self-serializing processors ensure that effects of a write to a control register are observable before processing the next instruction. Thus, this method assumes the worst case scenario that after an instruction that modifies a control register, the next instruction is dependent upon the modified control register. In self-serializing processors, the processor either stalls the machine pipeline until the write to the control register takes effect or flushes the machine pipeline to force the next instruction to be refetched after the control register has been modified. For example, early versions of the Intel.RTM. Pentium.RTM. processor flush the processor pipeline and refetch the instructions any time there is a write to a control register. If there are many successive modifications to control registers, this method can be very inefficient since each control register modification will stall or flush the machine pipeline.
The other known method of ensuring consistent results after a control register modification is to define a maximum latency time for each control register. Specifically, every implementation of the processor must exhibit the observable effects of the control register modification within the defined maximum latency time. Software written for processors with defined maximum latency times must not issue operations that depend upon a modified control register until the maximum latency time has expired. The responsibility for ensuring that such restrictions are followed is usually is given to the compilers for the processors. This technique requires that all the software be written to wait until the maximum latency has passed before scheduling dependent instructions even if the processor may be ready before maximum latency time. Thus, the software is written to fulfill a worst case latency time scenario even though the processor may be ready before maximum latency time has expired.
The two current methods of ensuring that the effects of a control register write are always observed at a well defined time each have disadvantages. In the case of a self-serializing processor, each instruction that modifies a control register will cause a pipeline stall or a pipeline flush with a subsequent refetch. In the case of a processor with defined maximum latency times, the software must be written not to violate a predefined maximum latency time even if that particular processor implementation would be ready earlier. It would therefore be desirable to implement an improved method of ensuring that the effects of a control register write are observed at a well defined time.